Life, Liberty, and the Pursuit of Agility

[NOTE: This post is about software development. You might need estimates in some other field or domain and this article is not related specifically to any other domain, and especially not the one you want to complain about.]

I’d like to do a little investigation about why we need estimates.

The following list contains some of the things people say when I ask “What do you use estimates* for in software development”:

• To decide if we can do a project affordably enough to make a profit.
• To decide what work we think we can do during “a Sprint”. (A decision about amount)
• To decide what work we should try to do during “a Sprint”. (A decision about priority or importance)
• To decide which is more valuable to us: this story or that story.
• To decide what project we should do: Project A or Project B.
• To decide how many developers/people to hire and how fast to “ramp up”.
• To decide how much money we’ll need to staff a team for a year.
• To give a price, or an approximate cost so a customer can decide to hire us to do their project.
• So we can determine the team’s velocity.
• So marketing can do whatever it is they do that requires they know 6 months in advance exactly what will be in our product.
• Someone told me to make an estimate, I don’t use them for anything.

That’s enough for a start. So let’s start.

Let’s notice the most obvious common word in that grouping. To me, it is the word “decide”. Granted, the last few items don’t use the word “decide”, but we have to start somewhere. Besides, why would have I contrived that list and highlighted the word “decide” if it wasn’t fundamental to my main point? [At least I’m honest in stating that I have an agenda.  Hint: NO ESTIMATES]

It is significant to me that much of why we do estimates is that we need to make decisions: To decide something.

In other words, it looks to me that what we need are decisions, not estimates. Estimates are often used to help us make decisions. Estimates are not the only way, and for many of the decisions we need to make they are likely not the best way, in my opinion. We can,  and maybe we should explore other ways to make those same decisions. [Who are we kidding, I really think we need to find better ways to make those decisions].

So to restate: We don’t need estimates, we need to make decisions.

Most of us will probably agree that decisions are important and we need to make them, and that we want to make “good” decisions. Great decisions are even better. Yet in many cases, mediocre decisions are sufficient [stay with me here…]

Interestingly, as long as we pay attention, learn from our mistakes, and are willing to make “course corrections” frequently, even bad decisions are often sufficient. In other words, even if we make bad decisions, we can adjust and steer our work (and therefore our results) by making decisions as we go along.  That is an important point. Dwell on it.

Perhaps it would be advantageous to find ways to work where the quality of our decisions are not as important as our ability to learn and to adjust our course while paying as little as possible for the learning, adjusting, and “mistakes”.

To me, this is a “Lean approach” to making software. To me, this is the “Agile way”. Some people used to call this a “light-weight methodology” for developing software to indicate the process was “barely sufficient” rather than “cripplingly  comprehensive and depressingly dysfunctional”. I like “light-weight”, but someone picked the name “Agile” for this idea. I like that word even better. Regardless of the name, it’s an approach where we pay attention to what is going on and constantly adjust things based on what we learn.

One other thing about decisions

Sometimes decisions happen by default: If I forgot to bring my lunch, my options are to go hungry or eat cafeteria food today. If I forgot to bring money, then the “decision” was made for me – I go hungry. I prefer to not go hungry, but in some cases a default decision is sufficient. Make decisions on important things, resort to default decisions on less important things. Besides, I need to lose some weight anyway.

One other other thing about decisions

One little note: Of the items in the “What do you use estimates for in software development” list above, there is only one where estimates seem to make sense to me: To decide how much money we’ll need to staff a team for a year.  I’ll write about that someday if anyone is interested.  But I am confident you can figure it out yourself.  Also, there are only a couple of items in that list that seem like important decisions to me. But what do I know?

One other other other thing

As far as the “team velocity” question goes – you don’t need an estimate for that. To determine the velocity of a team simply drop them from a height of about 2000 feet and you can measure their speed just before they hit the ground.  I’ve never tried that, but I’ve worked some places where it felt like that.

In Conclusion… We need to make decisions, we don’t need estimates.  Did I say that already?

So the title of this post was “Why do we need estimates?”. The answer is, we need them only if we can’t find a better way to make decisions.

There is a lot of stuff we need to decide, which requires that we make decisions. Make many small decisions while you learn, steer, adjust, and correct.

Some other posts I’ve written on the topic of estimating:

Perhaps you are now saying: So what? I don’t know of a better way, so I am going to use estimates. Besides, what’s so bad about estimates?  Well… I’ve written a little about that (although I’ve really just started – there is a LOT of potentially bad stuff about estimates we should all be aware of), and about a few alternatives to using estimates. Over time, I’ll keep adding more information, and share more about how to make decisions without estimates. In the mean-time, I know that many others are also finding ways to make great decisions without estimates, and some of them are writing about it as well.  Google that.  You can probably figure this stuff out better on your own, anyway.

• Estimation is Easy and Useful: Estimate a game of Chess
• Do Estimates Do What We Want Them To Do?
• No Estimate Programming Series – Intro Post
• No Estimate Approach For End-Of-Life Legacy Support
• Notes From A Conference Session On No Estimates in Software Development
• A Comment And Response from Estimate Chess Post
• Can We Code Without Estimates?
• If You Found Estimates Bring No Value – What Would You Do?

NOTES:

* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.

Disclaimer: There are many situations where estimates can be meaningful and useful.  This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.